Correspondência de Padrões JavaScript & Segurança de Tipos: Um Guia para Verificação em Tempo de Compilação

A correspondência de padrões é um dos recursos mais poderosos e expressivos na programação moderna, celebrada há muito tempo em linguagens funcionais como Haskell, Rust e F#. Ela permite que os desenvolvedores desconstruam dados e executem código com base em sua estrutura de maneira concisa e incrivelmente legível. À medida que o JavaScript continua a evoluir, os desenvolvedores estão cada vez mais buscando adotar esses paradigmas poderosos. No entanto, um desafio significativo permanece: como podemos alcançar a robusta segurança de tipos e as garantias em tempo de compilação dessas linguagens no mundo dinâmico do JavaScript?

A resposta está em aproveitar o sistema de tipos estáticos do TypeScript. Embora o próprio JavaScript esteja se aproximando da correspondência de padrões nativa, sua natureza dinâmica significa que quaisquer verificações ocorrerão em tempo de execução, possivelmente levando a erros inesperados na produção. Este artigo é um mergulho profundo nas técnicas e ferramentas que permitem a verdadeira verificação de padrões em tempo de compilação, garantindo que você detecte erros não quando seus usuários o fizerem, mas quando você digitar.

Vamos explorar como construir sistemas robustos, autodocumentados e resistentes a erros, combinando os recursos poderosos do TypeScript com a elegância da correspondência de padrões. Prepare-se para eliminar uma classe inteira de bugs em tempo de execução e escrever código mais seguro e fácil de manter.

O que é exatamente a Correspondência de Padrões?

Em sua essência, a correspondência de padrões é um mecanismo de fluxo de controle sofisticado. É como uma instrução `switch` superalimentada. Em vez de apenas verificar a igualdade em relação a valores simples (como números ou strings), a correspondência de padrões permite que você verifique um valor em relação a 'padrões' complexos e, se uma correspondência for encontrada, vincule variáveis a partes desse valor.

Vamos contrastá-lo com as abordagens tradicionais:

A maneira antiga: cadeias `if-else` e `switch`

Considere uma função que calcula a área de uma forma geométrica. Com uma abordagem tradicional, seu código pode ter esta aparência:

            
// Shape é um objeto com uma propriedade 'type'
function calcularArea(shape) {
  if (shape.type === 'circle') {
    return Math.PI * shape.radius * shape.radius;
  } else if (shape.type === 'square') {
    return shape.sideLength * shape.sideLength;
  } else if (shape.type === 'rectangle') {
    return shape.width * shape.height;
  } else {
    throw new Error('Tipo de forma não suportado');
  }
}

            

              
                Copy
              
            
          

Isso funciona, mas é verboso e propenso a erros. E se você adicionar uma nova forma, como um `triangle`, mas esquecer de atualizar essa função? O código lançará um erro genérico em tempo de execução, que pode estar longe de onde o bug real foi introduzido.

A maneira de correspondência de padrões: declarativa e expressiva

A correspondência de padrões reformula essa lógica para ser mais declarativa. Em vez de uma série de verificações imperativas, você declara os padrões que espera e as ações a serem tomadas:

            
// Pseudocódigo para um futuro recurso de correspondência de padrões JavaScript
function calcularArea(shape) {
  match (shape) {
    when ({ type: 'circle', radius }): return Math.PI * radius * radius;
    when ({ type: 'square', sideLength }): return sideLength * sideLength;
    when ({ type: 'rectangle', width, height }): return width * height;
    default: throw new Error('Tipo de forma não suportado');
  }
}

            

              
                Copy
              
            
          

Os principais benefícios são imediatamente aparentes:

• Desestruturação: Valores como `radius`, `width` e `height` são automaticamente extraídos do objeto `shape`.
• Legibilidade: A intenção do código é mais clara. Cada cláusula `when` descreve uma estrutura de dados específica e sua lógica correspondente.
• Exaustividade: Este é o benefício mais crucial para a segurança de tipos. Um sistema de correspondência de padrões verdadeiramente robusto pode avisá-lo em tempo de compilação se você esqueceu de lidar com um caso possível. Este é o nosso objetivo principal.

O Desafio do JavaScript: Dinamismo vs. Segurança

A maior força do JavaScript — sua flexibilidade e natureza dinâmica — também é sua maior fraqueza quando se trata de segurança de tipos. Sem um sistema de tipos estáticos que imponha contratos em tempo de compilação, a correspondência de padrões em JavaScript simples se limita a verificações em tempo de execução. Isso significa:

• Sem garantias em tempo de compilação: Você não saberá que perdeu um caso até que seu código seja executado e atinja esse caminho específico.
• Falhas silenciosas: Se você esquecer um caso padrão, um valor sem correspondência pode simplesmente resultar em `undefined`, causando bugs sutis a jusante.
• Pesadelos de refatoração: Adicionar uma nova variante a uma estrutura de dados (por exemplo, um novo tipo de evento, um novo status de resposta da API) requer uma pesquisa e substituição global para encontrar todos os lugares que precisam ser tratados. Perder um pode quebrar seu aplicativo.

É aqui que o TypeScript muda o jogo completamente. Seu sistema de tipos estáticos nos permite modelar nossos dados com precisão e, em seguida, aproveitar o compilador para garantir que lidemos com todas as variações possíveis. Vamos explorar como.

Técnica 1: A Fundação com Uniões Discriminadas

O recurso TypeScript mais importante para habilitar a correspondência de padrões com segurança de tipos é a união discriminada (também conhecida como união marcada ou tipo de dados algébrico). É uma maneira poderosa de modelar um tipo que pode ser uma de várias possibilidades distintas.

O que é uma União Discriminada?

Uma união discriminada é construída a partir de três componentes:

1. Um conjunto de tipos distintos (os membros da união).
2. Uma propriedade comum com um tipo literal, conhecido como discriminante ou tag. Essa propriedade permite que o TypeScript restrinja o tipo específico dentro da união.
3. Um tipo de união que combina todos os tipos de membros.

Vamos remodelar nosso exemplo de forma usando esse padrão:

            
// 1. Defina os tipos de membros distintos
interface Circle {
  kind: 'circle'; // O discriminante
  radius: number;
}

interface Square {
  kind: 'square'; // O discriminante
  sideLength: number;
}

interface Rectangle {
  kind: 'rectangle'; // O discriminante
  width: number;
  height: number;
}

// 2. Crie o tipo de união
type Shape = Circle | Square | Rectangle;

            

              
                Copy
              
            
          

Agora, uma variável do tipo `Shape` deve ser uma dessas três interfaces. A propriedade `kind` age como a chave que desbloqueia os recursos de estreitamento de tipo do TypeScript.

Implementando a Verificação de Exaustividade em Tempo de Compilação

Com nossa união discriminada em vigor, agora podemos escrever uma função que é garantida pelo compilador para lidar com todas as formas possíveis. O ingrediente mágico é o tipo `never` do TypeScript, que representa um valor que nunca deve ocorrer.

Podemos escrever uma função auxiliar simples para impor isso:

            
function assertUnreachable(x: never): never {
  throw new Error("Não esperava chegar aqui");
}

            

              
                Copy
              
            
          

Agora, vamos reescrever nossa função `calculateArea` usando uma instrução `switch` padrão. Observe o que acontece no caso `default`:

            
function calculateArea(shape: Shape): number {
  switch (shape.kind) {
    case 'circle':
      // TypeScript sabe que `shape` é um Circle aqui!
      return Math.PI * shape.radius ** 2;

    case 'square':
      // TypeScript sabe que `shape` é um Square aqui!
      return shape.sideLength ** 2;

    case 'rectangle':
      // TypeScript sabe que `shape` é um Rectangle aqui!
      return shape.width * shape.height;

    default:
      // Se tratarmos todos os casos, `shape` será do tipo `never`
      return assertUnreachable(shape);
  }
}

            

              
                Copy
              
            
          

Este código compila perfeitamente. Dentro de cada bloco `case`, o TypeScript restringiu o tipo de `shape` para `Circle`, `Square` ou `Rectangle`, permitindo que acessemos propriedades como `radius` com segurança.

Agora, para o momento mágico. Vamos apresentar uma nova forma ao nosso sistema:

            
interface Triangle {
  kind: 'triangle';
  base: number;
  height: number;
}

type Shape = Circle | Square | Rectangle | Triangle; // Adicione-o à união

            

              
                Copy
              
            
          

Assim que adicionarmos `Triangle` à união `Shape`, nossa função `calculateArea` produzirá imediatamente um erro em tempo de compilação:

            
// No bloco `default` de `calculateArea`:

return assertUnreachable(shape);
//                      ~~~~~
// Argumento do tipo 'Triangle' não é atribuível ao parâmetro do tipo 'never'.

            

              
                Copy
              
            
          

Este erro é incrivelmente valioso. O compilador TypeScript está nos dizendo: "Você prometeu lidar com cada `Shape` possível, mas esqueceu do `Triangle`. A variável `shape` ainda pode ser um `Triangle` no caso padrão, e isso não é atribuível a `never`."

Para corrigir o erro, basta adicionar o caso ausente. O compilador se torna nossa rede de segurança, garantindo que nossa lógica permaneça sincronizada com nosso modelo de dados.

            
// ... dentro do switch
    case 'triangle':
      return 0.5 * shape.base * shape.height;

    default:
      return assertUnreachable(shape);
// ... agora o código compila novamente!

            

              
                Copy
              
            
          

Prós e Contras desta Abordagem

• Prós:
  • Zero Dependências: Ele usa apenas os recursos principais do TypeScript.
  • Máxima Segurança de Tipos: Fornece garantias irrefutáveis em tempo de compilação.
  • Excelente Desempenho: Ele compila para uma instrução `switch` JavaScript padrão altamente otimizada.
• Contras:
  • Verbosidade: O boilerplate `switch`, `case`, `break`/`return` e `default` pode parecer complicado.
  • Não é uma Expressão: Uma instrução `switch` não pode ser retornada diretamente ou atribuída a uma variável, levando a estilos de código mais imperativos.

Técnica 2: APIs ergonômicas com bibliotecas modernas

Embora a união discriminada com uma instrução `switch` seja a base, seu boilerplate pode ser tedioso. Isso levou à ascensão de bibliotecas de código aberto fantásticas que fornecem uma API mais funcional, expressiva e ergonômica para correspondência de padrões, ao mesmo tempo em que aproveitam o compilador do TypeScript para segurança.

Apresentando `ts-pattern`

Uma das bibliotecas mais populares e poderosas nesse espaço é a `ts-pattern`. Ele permite que você substitua as instruções `switch` por uma API fluente e encadeável que funciona como uma expressão.

Vamos reescrever nossa função `calculateArea` usando `ts-pattern`:

            
import { match } from 'ts-pattern';

function calculateAreaWithTsPattern(shape: Shape): number {
  return match(shape)
    .with({ kind: 'circle' }, (s) => Math.PI * s.radius ** 2)
    .with({ kind: 'square' }, (s) => s.sideLength ** 2)
    .with({ kind: 'rectangle' }, (s) => s.width * s.height)
    .with({ kind: 'triangle' }, (s) => 0.5 * s.base * s.height)
    .exhaustive(); // Esta é a chave para a segurança em tempo de compilação
}

            

              
                Copy
              
            
          

Vamos analisar o que está acontecendo:

• `match(shape)`: Isso inicia a expressão de correspondência de padrões, recebendo o valor a ser correspondido.
• `.with({ kind: '...' }, manipulador)`: Cada chamada `.with()` define um padrão. `ts-pattern` é inteligente o suficiente para inferir o tipo do segundo argumento (a função `handler`). Para o padrão `{ kind: 'circle' }`, ele sabe que a entrada `s` para o manipulador será do tipo `Circle`.
• `.exhaustive()`: Este método é o equivalente ao nosso truque `assertUnreachable`. Ele diz ao `ts-pattern` que todos os casos possíveis devem ser tratados. Se removêssemos a linha `.with({ kind: 'triangle' }, ...)` , `ts-pattern` dispararia um erro em tempo de compilação na chamada `.exhaustive()`, informando que a correspondência não é exaustiva.

Recursos avançados do `ts-pattern`

`ts-pattern` vai muito além da simples correspondência de propriedades:

• Correspondência de predicados com `.when()`: Correspondência baseada em uma condição.

              
  match(input)
    .when(isString, (str) => `É uma string: ${str}`)
    .when(isNumber, (num) => `É um número: ${num}`)
    .otherwise(() => 'É outra coisa');
  
              
  
                
                  Copy
                
              
            

• Padrões profundamente aninhados: Correspondência em estruturas de objetos complexas.

              
  match(user)
    .with({ address: { city: 'Paris' } }, () => 'Usuário está em Paris')
    .otherwise(() => 'Usuário está em outro lugar');
  
              
  
                
                  Copy
                
              
            

• Curingas e Seletores Especiais: Use `P.select()` para capturar um valor dentro de um padrão ou `P.string`, `P.number` para corresponder a qualquer valor de um determinado tipo.

              
  import { match, P } from 'ts-pattern';
  
  match(event)
    .with({ type: 'USER_LOGIN', user: { name: P.select() } }, (name) => {
      console.log(`${name} fez login.`);
    })
    .otherwise(() => {});
  
              
  
                
                  Copy
                
              
            

Ao usar uma biblioteca como `ts-pattern`, você obtém o melhor dos dois mundos: a robusta segurança em tempo de compilação da verificação `never` do TypeScript, combinada com uma API limpa, declarativa e altamente expressiva.

O futuro: a Proposta de Correspondência de Padrões do TC39

A própria linguagem JavaScript está no caminho para obter correspondência de padrões nativa. Existe uma proposta ativa no TC39 (o comitê que padroniza JavaScript) para adicionar uma expressão `match` à linguagem.

Sintaxe Proposta

A sintaxe provavelmente se parecerá com isto:

            
// Esta é a sintaxe JavaScript proposta e pode mudar
const getMessage = (response) => {
  return match (response) {
    when ({ status: 200, body: b }) { return `Sucesso com corpo: ${b}`; }
    when ({ status: 404 }) { return 'Não encontrado'; }
    when ({ status: s if s >= 500 }) { return `Erro do servidor: ${s}`; }
    default { return 'Resposta desconhecida'; }
  }
};

            

              
                Copy
              
            
          

E quanto à Segurança de Tipos?

Esta é a questão crucial para nossa discussão. Por si só, um recurso nativo de correspondência de padrões JavaScript executaria suas verificações em tempo de execução. Ele não saberia sobre seus tipos TypeScript.

No entanto, é quase certo que a equipe do TypeScript construiria análise estática sobre essa nova sintaxe. Assim como o TypeScript analisa as instruções `if` e os blocos `switch` para realizar a restrição de tipo, ele analisaria as expressões `match`. Isso significa que poderíamos obter o melhor resultado possível:

1. Sintaxe nativa e de alto desempenho: Sem necessidade de bibliotecas ou truques de transpilação.
2. Segurança total em tempo de compilação: TypeScript verificaria a expressão `match` para exaustividade em relação a uma união discriminada, assim como faz hoje para `switch`.

Enquanto esperamos que esse recurso chegue às etapas da proposta e entre nos navegadores e runtimes, as técnicas que discutimos hoje com uniões discriminadas e bibliotecas são a solução pronta para produção e de última geração.

Aplicações Práticas e Melhores Práticas

Vamos ver como esses padrões se aplicam a cenários comuns de desenvolvimento do mundo real.

Gerenciamento de Estado (Redux, Zustand, etc.)

Gerenciar o estado com ações é um caso de uso perfeito para uniões discriminadas. Em vez de usar constantes de string para tipos de ação, defina uma união discriminada para todas as ações possíveis.

            
// Defina ações
interface IncrementAction { type: 'counter/increment'; payload: number; }
interface DecrementAction { type: 'counter/decrement'; payload: number; }
interface ResetAction { type: 'counter/reset'; }

type CounterAction = IncrementAction | DecrementAction | ResetAction;

// Um redutor com segurança de tipos
function counterReducer(state: number, action: CounterAction): number {
  return match(action)
    .with({ type: 'counter/increment' }, (act) => state + act.payload)
    .with({ type: 'counter/decrement' }, (act) => state - act.payload)
    .with({ type: 'counter/reset' }, () => 0)
    .exhaustive();
}

            

              
                Copy
              
            
          

Agora, se você adicionar uma nova ação à união `CounterAction`, o TypeScript o forçará a atualizar o redutor. Chega de manipuladores de ação esquecidos!

Manipulação de Respostas da API

Buscar dados de uma API envolve vários estados: carregamento, sucesso e erro. Modelar isso com uma união discriminada torna a lógica da sua IU muito mais robusta.

            
// Modele o estado de dados assíncronos
type RemoteData<T, E> =
  | { status: 'idle' }
  | { status: 'loading' }
  | { status: 'success'; data: T }
  | { status: 'error'; error: E };

// No seu componente de IU (por exemplo, React)
function UserProfile({ userId }: { userId: string }) {
  const [userState, setUserState] = useState<RemoteData<User, Error>>({ status: 'idle' });

  // ... useEffect para buscar dados e atualizar o estado ...

  return match(userState)
    .with({ status: 'idle' }, () => <p>Clique em um botão para carregar o usuário.</p>)
    .with({ status: 'loading' }, () => <Spinner />)
    .with({ status: 'success' }, (state) => <UserProfileCard user={state.data} />)
    .with({ status: 'error' }, (state) => <ErrorMessage error={state.error} />)
    .exhaustive();
}

            

              
                Copy
              
            
          

Essa abordagem garante que você implementou uma IU para todos os estados possíveis da sua busca de dados. Você não pode esquecer acidentalmente de lidar com o caso de carregamento ou erro.

Resumo das Melhores Práticas

• Modele com Uniões Discriminadas: Sempre que você tiver um valor que pode ser uma de várias formas distintas, use uma união discriminada. É a base de padrões com segurança de tipos em TypeScript.
• Sempre imponha a exaustividade: Quer você use o truque `never` com uma instrução `switch` ou o método `.exhaustive()` de uma biblioteca, nunca deixe uma correspondência de padrão em aberto. É daí que vem a segurança.
• Escolha a ferramenta certa: Para casos simples, uma instrução `switch` é aceitável. Para lógica complexa, correspondência aninhada ou um estilo mais funcional, uma biblioteca como `ts-pattern` melhorará significativamente a legibilidade e reduzirá o boilerplate.
• Mantenha os padrões legíveis: O objetivo é clareza. Evite padrões excessivamente complexos e aninhados que sejam difíceis de entender à primeira vista. Às vezes, dividir uma correspondência em funções menores é uma abordagem melhor.

Conclusão: Escrevendo o Futuro do JavaScript Seguro

A correspondência de padrões é mais do que apenas açúcar sintático; é um paradigma que leva a um código mais declarativo, legível e — o mais importante — mais robusto. Embora aguardemos ansiosamente sua chegada nativa no JavaScript, não precisamos esperar para colher seus benefícios.

Ao aproveitar o poder do sistema de tipos estáticos do TypeScript, particularmente com uniões discriminadas, podemos construir sistemas que podem ser verificados em tempo de compilação. Essa abordagem muda fundamentalmente a detecção de bugs do tempo de execução para o tempo de desenvolvimento, economizando incontáveis horas de depuração e evitando incidentes de produção. Bibliotecas como `ts-pattern` constroem sobre essa base sólida, fornecendo uma API elegante e poderosa que torna a escrita de código com segurança de tipos uma alegria.

Adotar a verificação de padrões em tempo de compilação é um passo em direção à escrita de aplicativos mais resilientes e fáceis de manter. Ele incentiva você a pensar explicitamente sobre todos os estados possíveis em que seus dados podem estar, eliminando a ambiguidade e tornando a lógica do seu código clara como cristal. Comece a modelar seu domínio com uniões discriminadas hoje e deixe o compilador TypeScript ser seu parceiro incansável na construção de software sem bugs.